Technique for interconnecting circuit-switched and packet-switched domains

ABSTRACT

A technique for interconnecting circuit-switched (CS) and packet-switched (PS) domains enables network components ( 302 ) having a PS network access to make use of CS telephony services. A method embodiment of this technique comprises the steps of receiving PS control information according to a PS control protocol such as SIP, determining, in response to receipt of the PS control information, CS control information according to a CS control protocol such as DTAP, and sending the determined CS control information to a second network component ( 324 ) that is located on an application (or service) layer for provision of CS services, based on the determined CS control information, to the first network component ( 302 ).

FIELD OF THE INVENTION

The present invention generally relates to a technique forinterconnecting circuit-switched (CS) and packet-switched (PS) domains.In particular, the invention relates to the provision of CS services toa network component having a PS network access.

BACKGROUND OF THE INVENTION

The Internet protocol (IP) multimedia subsystem (IMS) defined by the3^(rd) generation partnership project (3GPP) represents a PS servicedelivery platform architecture for the provision of IP multimediaservices within emerging all-IP network environments. The IMS comprisesthree main components: the serving call session control function(S-CSCF) on a control layer, and the home subscriber server (HSS) aswell as the session initiation protocol (SIP) application server(SIP-AS) on an application layer.

During operation, the S-CSCF forwards SIP messages received from userterminals or other network components to the SIP-AS. Based on thereceived SIP messages, the SIP-AS determines the services that are to beprovided to a particular user. During the execution of a particularservice, the SIP-AS may require additional information about a user andmay to this end communicate with the HSS. The HSS stores a serviceprofile for each user and can thus be regarded as the equivalent to thehome location register (HLR) in conventional second (and third)generation networks such as GSM (global system for mobile communication)networks.

IMS has been preceded by a change in network topology—that is, themigration towards layered network architectures. Whereas in conventionalsecond generation networks a single component, the mobile switchingcenter (MSC), handles both call control and connectivity, in layerednetworks these functionalities have been split. More specifically, callcontrol is handled by MSC servers (MSC-S) in the control layer, whereasconnectivity is handled by media gateways (MGW) in the connectivitylayer. This separation of call control and connectivity is also referredto as mobile softswitching (MSS).

The MSC-S handles the network signalling and intelligence for settingup, releasing and monitoring CS connections. The MGW, on the other hand,processes and manages the transport of CS payload traffic (such as voiceor data traffic). The MGW additionally provides interconnections toexternal networks including public switched telephone networks (PSTNs)and public land mobile networks (PLMNs).

Network operators with an installed MSS environment or with theintention to deploy MSS will want to ensure a smooth transition from MSSand the CS domain to an all-IP solution. From a migration perspective,and also with regard to a reuse of installed equipment, operators willpreferably use CS services (such as CS telephony services) during aco-existence period also for IMS subscribers having PS network access.

The object underlying the invention is to propose a technique forinterconnecting CS and PS domains. In particular, a technique forproviding CS services to a network component having a PS network accessis required.

SUMMARY OF THE INVENTION

According to a first aspect of the invention, a method of controllingthe provision of CS services to a first network component having a PSnetwork access is provided, wherein the method comprises receiving PScontrol information according to a PS control protocol, determining, inresponse to receipt of the PS control information, CS controlinformation according to a CS control protocol, and sending thedetermined CS control information to a second network component that islocated on an application (or service) layer for controlling, based onthe determined CS control information, provision of CS services to thefirst network component.

The PS control information may include at least one of one or more PScontrol messages and one or more PS control parameters. In onevariation, the PS control messages are SIP messages and the PS controlparameters are SIP parameters. The CS control information may include atleast one of one or more CS control messages and one or more CS controlparameters. In one variation, the CS control messages are base stationsystem management application part (BSSMAP) messages or direct transferapplication part (DTAP) messages, and the CS control parameters are DTAPparameters or BSSMAP parameters. The CS control information may compriseone or more of information pertaining to a requested service type (suchas voice, video, multimedia, etc.), information required to establish CSservices, information about how to execute CS services, and informationabout the status or result of CS services (e.g., indicating a successfulservice establishment or a service establishment failure).

The determination of the CS control information may be performed invarious ways. In a first example, the CS control information isencapsulated in the PS control information (e.g. in a PS controlmessage), and the step of determining the CS control informationincludes de-encapsulating the encapsulated CS control information (suchas one or more CS control parameters) from the PS control information.In a second example, that can be combined with the first example, thestep of determining the CS control information includes mapping the PScontrol information to the CS control information.

The step of determining the CS control information can be performed onthe control layer, on the application layer or on any intermediatelayer. It is also possible that the determination step includes severalsub-steps that are performed on different layers. Preferably, the CScontrol information is determined by services intermediating between aPS control layer and a CS application layer.

Several information handling services may be provided (preferably in thePS domain) for a flexible control of the information flow. The flexiblecontrol of the information flow facilitates migration towards an all-IPenvironment. In one example, first services (such as an SIP-AS)interpreting the PS control information by default and second services(such as a dedicated AS) capable of determining the CS controlinformation are provided. The individual services may be co-located in asingle hardware component or may be dispersed among various hardwarecomponents.

According to a first scenario, the received PS control information isfirst routed to the first services, and then re-routed from the firstservices to the second services. The re-routing may be performed on aselective basis (i.e., the second services may see only a part of thereceived PS information). To this end, the first services may perform adecision step to determine whether or not to re-route the PS controlinformation. This decision step can be based on a service portfolio ofthe first services. If, for example, the first services can provide orcontrol the requested services themselves, no re-routing will occur. If,on the other hand, the first services can not provide or control therequested services, the re-routing step towards the second services willbe performed. The decision step can additionally, or in the alternative,be based on a request included in the received PS control information.The request may take the form of an indicator sent from the firstnetwork component (e.g. from a user terminal) that a specific service isto be executed by the first or second services. The request may beincluded by the first network component, by a network operator, or byany other network entity. By such a mechanism, the first networkcomponent or the network operator may for example control whether aparticular service is to be provided in the PS domain (via the firstservices) or in the CS domain (via the second services).

According to a second scenario, that can be combined with the firstscenario, the received PS control information is selectively routed toeither the first services or the second services. This selective routingmay be performed by a network component on a control layer such as aCSCF. The decision whether to route the PS control information to thefirst services or to the second services may be dependent upon one ormore of the following criteria: the CS services requested,load-balancing considerations, capabilities of the first networkcomponent, trigger events defined by a network operator, user requests,and user service profiles.

According to a third scenario, that can be combined with any one or bothof the first and second scenario, it is possible that both the firstservices and second services are invoked. This approach is particularlyuseful when a part of the requested services are executed in the PSdomain (via the first services) and another part in the CS domain (viathe second services). Note that it may even happen that the firstservices (PS) modify PS information upon which the second services (CS)are invoked by a controlling network component when the first servicesreturn the control to the controlling network component (or vice versa).

The network component on the application layer which provides therequested CS services can by arranged in a conventional CS network. Inone variation, the CS services are provided by component of a layeredMSS network. In such a case, the CS services can be provided by a MSCserver (MSC-S). The MSC-S can be transferred from the control layer(where it will conventionally be located) to the application layer andmay additionally be relieved of its control tasks.

Until now, the information flow from the PS domain to the CS domain hasbeen described. Of course, the information could also flow in the otherdirection from the CS domain to the PS domain. In such a case, themethod could further comprise the steps of receiving CS controlinformation and determining corresponding PS control information as aresponse to receipt of the CS control information. The PS controlinformation thus determined could then be sent to the first networkcomponent having PS network access (e.g. a user terminal) or any othernetwork component in the PS domain.

Upon initiation of the information flow, the first network component canget registered in the PS domain. Additionally, the first networkcomponent can get registered in the CS domain (e.g., using the protocolconversion steps discussed above or any other approach).

The invention can be implemented as software, as hardware or as asoftware/hardware combination. As regards a software aspect, a computerprogram product comprising program code portions for performing thesteps of the above methods when the computer program product is run onone or more computing devices is provided. The computer program productmay be stored on a computer readable recording medium.

According to a hardware aspect of the invention, a device forinterconnecting PS and CS domains is provided. The device comprises acontrol component for receiving PS A control information according to aPS control protocol, a protocol converter for determining, in responseto receipt of the PS control information, CS control informationaccording to a CS control protocol, and an interface for sending thedetermined CS control information to a serving network component that islocated on an application layer and provides the CS services based onthe determined CS control information.

The protocol converter preferably includes program code for at least oneof mapping the received PS control information to predefined CS controlinformation and de-encapsulating the CS control information from the PScontrol information. The protocol converter may be co-located with oneof the control component, the serving network component and a servicecomponent that handles the PS control information by default.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, the invention will be described with reference toexemplary embodiments illustrated in the Figs., in which:

FIG. 1A is a schematic flow chart illustrating a first method embodimentof the present invention;

FIG. 1B is a schematic flow chart illustrating a second methodembodiment of the present invention;

FIG. 2 is a schematic block diagram showing a device embodiment of thepresent invention;

FIG. 3 is a schematic diagram showing a system embodiment of the presentinvention;

FIG. 4 is a schematic diagram showing a first configuration of a part ofthe system embodiment of FIG. 3; and

FIG. 5 is a schematic diagram showing a second configuration of a partof the system embodiment of FIG. 3.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the following description, for purposes of explanation and notlimitation, specific details are set forth, such as particular signalformats, messaging protocols, etc. in order to provide a thoroughunderstanding of the current invention. It will be apparent to oneskilled in the art that the current invention may be practised in otherembodiments that depart from these specific details. For example, theskilled artisan will appreciate that the current invention may bepractised with PS standards different from the SIP standard discussedbelow to illustrate the present invention. Also, the invention may bepractised with CS standards different from the DTAP and BSSMAP standardsdiscussed below.

Those skilled in the art will further appreciate that functionsexplained herein below may be implemented using individual hardwarecircuitry, using software functioning in conjunction with a programmedmicro processor or general purpose computer, using an applicationspecific integrated circuit (ASIC), and/or using one or more digitalsignal processors (DSPs). It will also be appreciated that while thecurrent invention is primarily described as a method, it may also beembodied in a computer processor and a memory coupled to the processor,wherein the memory is encoded with one or more programs that perform themethods disclosed herein.

With reference to FIG. 1A, a flow chart 100 shows the individual stepsof a first method embodiment for interconnecting PS and CS domains withthe purpose of controlling the provision of CS services to a firstnetwork component having a PS network access.

In a first step 102, PS control information according to a PS controlprotocol is received via a first network. A next step 104 is performedin response to the receipt of PS control information in step 102. Instep 104, CS information according to a CS protocol is determined. In athird step 106, the determined CS control information is sent to asecond network component located on an application (or service) layer.Under control of the received CS control information, the second networkcomponent provides CS services to the first network component.

With reference to FIG. 1B, a flow chart 110 shows the individual stepsof a second method embodiment for interconnecting PS and CS domains.

In a first step 112, one or more first control messages according to aPS control protocol are received via a first network. The one or morefirst control messages include service information that relates to theprovision of CS services such as telephony services or multimediaservices.

In a next step 114, the service information is extracted or otherwisederived from the one or more first control messages.

In a third step 116, one or more second control messages according to aCS control protocol are generated. The one or more second controlmessages are generated based on the service information determined instep 114.

In a fourth step 118, the one or more generated second control messagesare sent to CS application services that are to be controlled (e.g.,initiated, terminated, etc.) by the one or more second control messages.

The steps shown in FIGS. 1A and 1B show an information flow from the PSdomain towards the CS domain. It will be appreciated that the steps canbe performed in an analogous manner for an information flow from the CSdomain towards the PS domain.

FIG. 2 shows a protocol conversion device 200 in which the above methodsfor interconnecting PS and CS domains can be practised. The device 200comprises an information reception component 202, a protocol converter204 and an interface 206.

The component 202 is configured to receive PS control information suchas one or more first control messages according to a PS controlprotocol. The component 202 is coupled to the protocol converter 204 andcapable of transferring the received PS information to the protocolconverter 204. In response to receipt of the PS information, theprotocol converter determines CS control information according to a CScontrol protocol. To this end, the protocol converter 204 maps thereceived PS information to CS information, extracts CS information fromthe received PS information, or performs any other steps.

As can be seen in FIG. 2, the protocol converter 204 is coupled to theinterface 206. The interface 206 allows the transfer of the CS controlinformation generated by the protocol converter 204 to a networkcomponent (not shown in FIG. 2) that is located on an application layerand that provides CS services under control of the transferred CScontrol information.

The interface 206 may additionally or alternatively be configured toreceive CS control information according to a CS control protocol.Moreover, in a similar manner as discussed above, the protocol converter204 can additionally or alternatively be capable of determining, inresponse to receipt of the CS control information, PS controlinformation according to the PS control protocol. The PS controlinformation thus determined may be sent via the reception component 202or any other component towards a PS network.

It should be noted that the protocol converter 204 may include one, twoor more individual services for performing the conversion steps.Additionally, the protocol converter 204 may be associated with aconfiguration component (not shown) specifying for example mappingcriteria, default messages, etc.

FIG. 3 shows an embodiment of a communication system 300 for providingend-to-end connections between various user terminals 302, 304 and 306.A first user terminal 302 is configured as SIP client and has access toa PS network 308. The PS network 308 may be a wired network, a wirelessnetwork or a combination of these two network types. The PS network 308may be configured as a WCDMA network or a WLAN. According to a furthervariation, the PS network may be a network operated under GSM within theregime of the general packet radio service (GPRS).

A second user terminal 304 is provided with access to an unlicensedmobile access (UMA) network 310. The UMA technology provides access toGSM and GPRS mobile services over unlicensed spectrum technologies,including Bluetooth and IEEE 802.11 standards. A third user terminal 308is provided with access to a CS network such as a PLMN.

The first user terminal 302 communicates via the PS network 308 with anIMS sub-system 314. The IMS sub-system 314 includes a (S-) CSCF on acontrol layer as well as a first application server 318 on theapplication layer. In the present embodiment, the first applicationserver 318 is configured as a SIP-AS or any other IMS-AS. An additionalsecond application server 320 that may or may not belong to the IMSsub-system 314 is configured as a dedicated MSS-AS.

SIP-D control messages are exchanged via the PS network 308 between thefirst user terminal 302 and the IMS sub-system 314. In the context ofthe present embodiment, SIP-D information denotes messages, parameters,etc. according to the SIP standard that include encapsulated DTAPinformation (DTAP messages, DTAP parameters, etc.). Within the IMSsub-system 314, the SIP-D messages that are sent from the first userterminal 302 are received by the CSCF 316 and routed to one or both ofthe application servers 318, 320. The application servers 318 and 320communicate via SIP-D messages with each other.

The system 300 further comprises a MSS sub-system 322 that implements alayered network architecture. The MSS sub-system 326 includes a MSC-S324 as well as a MGW 326. The MSC-S terminates and originates andre-routes control layer protocols and, importantly, additionallyapplication layer protocols. In non-layered networks, it would also bepossible to use a traditional (non-layered) MSC or even a telephonyserver or switch as available in wired networks.

The MSS sub-system 322 is coupled via the IMS sub-system 314 and the PSnetwork 308 to the first user terminal 302. The MSS sub-system 322 isadditionally coupled to the second user terminal 304 via a home basestation controller (HBSC) 328 and the UMA network 310. Furthermore, theMSS sub-system 322 is coupled via a base station controller (BSC) or aradio network controller (RNC) and the CS network 312 to the third userterminal 306.

In the system 300 shown in FIG. 3, the MSS-AS 320 is the crucialcomponent for providing the interworking between the IMS/PS domain andthe control layer (CSCF is 316) on the one hand and the MSS sub-system322 and the application layer (MSC-S 324), where conventional CSservices reside, on the other hand. Accordingly, the MSS-AS 320 ensuresthat CS telephony and other CS services that are needed in the PS/IMSdomain can easily be provided by operators with an installed MSSsub-system 322 or with the intention to deploy such a MSS sub-system322. At least during the transition phase from CS to IMS/PS, the MSS-AS320 is the entity that provides the compatibility. The MSS-AS 320 istherefore useful to network operators that prefer to utilize availableCS services also for PS/IMS subscribers.

In the following two different scenarios of providing telephony or otherservices to the first user terminal 302 will be discussed with referenceto the schematic diagrams shown in FIGS. 4 and 5 that are derived fromFIG. 3. In these scenarios, the DTAP or other service parametersrequired for providing the CS services in the MSS sub-system 322 aregenerated and encapsulated in a SIP-D message by a client componentwithin the first user terminal 302. The SIP-D message thus generated istransferred from the first user terminal 302 via the CSCF 316 (andoptionally via the SIP-AS 318) to the MSS-AS 320. The MSS-AS 320extracts the service parameters and generates a plain DTAP messageincluding the extracted service parameters. The MSS-AS 320 mayalternatively perform a mapping of SIP messages and parameters to DTAPmessages and parameters.

The DTAP messages and parameters may include service-related informationsuch as information about how to execute a particular service. Examplesof services are supplementary services (e.g. call forwarding or barringservices), CAMEL/IN services, routing to voice mail systems, etc.Additionally, the activation and deactivation and also the change ofsettings of services (called supplementary service invocations) viadedicated messages is possible (e.g. activation/deactivation of a callforwarding or the change of the call forwarded number). When BSSMAPmessages are generated in the MSS-AS 320, also mobility services likeroaming, handover, traffic channel assignment priority handling (e.g.eMLPP, as specified in 3GPP), etc. become feasible. This applies to GSM(A interface) and WCDMA (Iu interface) accesses, but also to any otheraccess type.

The DTAP messages generated by the MSS-320 are sent to the MSSsub-system 322 and more specifically to the MSC-S 324 of the MSSsub-system 322. When a call or session is routed to the MSS sub-system322, there are basically two options how to proceed further. Accordingto a first option, the MSS sub-system 322 executes the requested service(e.g. CAMEL/IN), possibly modifies some of the parameters (e.g. adestination number) and returns the call or session to the IMSsub-system 314 (CSCF 316). According to a second option the MSSsub-system 322 executes the requested service and remains in the CSdomain (i.e. the call or session is not returned to the IMS subsystem314 anymore). It should be noted that the latter option is not inaccordance with the pertinent standards (3GPP) as the application serveris supposed to return the call or session to the control node (e.g. tothe CSCF 316) but can nevertheless be implemented where appropriate.

Returning now to the service selection within the IMS domain, in thescenario shown in FIG. 4 the CSCF 316 selects the application servicesto which the SIP-D message that includes the service parameters will berouted. The CSCF 316 selects either the SIP-AS 318 or the MSS-AS 320depending upon the service specified in the service parameters. Towardsthe SIP-AS 318, the CSCF 316 uses either plain SIP or SIP-D, whereas theinterface to the MSS-AS 320 is SIP-D. In case both the SIP-AS 318 andthe MSS-AS 320 support the corresponding service, the selectionperformed by the CSCF 316 can be based on other criteria such as loadbalancing, terminal capabilities, user service profile (subscriberprofile), subscriber request, etc.

The MSS-AS 320 shown in FIG. 4 can be a stand-alone component orco-located with the SIP-AS 318 or any other IMS-AS. Alternatively, theMSS-AS 320 could be co-located with the CSCF 316 or with the MSC-S 324(as part of the MSS sub-system 322). Some of the possible locations ofthe MSS-AS 320 are indicated in FIG. 4 by dashed lines.

In a further scenario similar to FIG. 4, the CSCF 316 selects both theSIP-AS 318 and the MSS-AS 320. Such an approach may be advantageous ifsome services are to be provided in the PS domain (via the SIP-AS 318)while other services are at the same time to be provided in the CSdomain (via the MSS-AS 320 and the MSC-S 324).

In the scenario of FIG. 5, an alternative messaging picture is shown.Here, the CSCF 316 routes any SIP-D messages that include a servicerequest from the user terminal 302 by default to the SIP-AS 318.Accordingly, the CSCF 316 does not need any knowledge about theexistence of the MSS-AS 320. In cases in which the SIP-AS 318 does notyet support the requested service, or in other cases, it re-routes theSIP-D message received from the CSCF 316 to the MSS-AS 320. Accordingly,the selection of the MSS-AS 320 is here performed by the SIP-AS 318depending upon its own capabilities. This approach is preferred from amigration point of view. Also, the approach allows hiding of the servicecapabilities on the application layer from the CSCF 316, i.e. from theIMS core. Just as in FIG. 4, the MSS-AS 320 may again be a stand-alonecomponent or co-located with for example the SIP-AS 318 or the MSC-S 324as part of the MSS (see dashed lines).

In the scenarios discussed above, the relevant DTAP service parametersmay alternatively by specified in SIP-UNI messages. The SIP-UNI messagesincluding these parameters may then be transferred from the first userterminal 302 to the application layer as discussed above. It should benoted that more and more service parameters are expected to be specifiedin the SIP-UNI standard. In some cases, BSSMAP messaging may be used inthe CS domain in addition to DTAP messages. DTAP and BSSMAP messages maybe transported via the signalling layer 7 (SS7) or the Sigran standard.Also, SCTP/IP or TCP/IP could be used.

When the PS user terminal 302 initially registers in the CSCF 316, italso may be registered in the CS domain. This may be done directly viathe MSS-AS 320 (DTAP/BSSMAP messaging) in the MSC-S 324 and the HLR orHSS (not shown in FIG. 3). It may also be done in such a way that theMSS-AS 320 stores the registration information and registers in MSC-S324 and HLR/HSS when the MSS-AS 320 is invoked (as that may actuallynever happen while the subscriber is roaming in the corresponding PSaccess network). Once the subscriber is registered in the HLR/HSS, theHLR/HSS can be invoked by the MSC-S 324 for the subscriber profile(supported services etc.). It should be noted that the operator stillhas to enter the subscriber in the HLR/HSS as is done for normal CSsubscribers.

While a particular conversion scenario is shown in FIG. 3(de-encapsulation of DTAP from SIP-D), the MSS-AS may additionally oralternatively be configured to convert relevant information from SIP toDTAP (e.g. map SIP messages and parameters to DTAP messages andparameters), convert relevant information from SIP to BSSMAP (e.g. mapSIP messages and parameters to BSSMAP messages and parameters), generateDTAP messages based on other criteria (e.g. operator settings, usersettings or default parameters), generate BSSMAP messages based on othercriteria (e.g. operator settings, user settings or default parameters),and vice versa. It will be appreciated that SIP messages may also beconverted into DTAP parameters and SIP parameters may be converted intoDTAP messages (and vice versa). It should additionally be noted thatthere may be an n:m relation between the messages and parameters on thePS and CS sides. This also implies that the MSS-AS may need to wait fora second message from the PS domain before a corresponding message issent to the MSC-S (and vice versa).

The protocol conversion steps discussed above ensure a highcompatibility between PS architectures such as IMS on the one hand andCS architectures such as MSS on the other hand. This compatibilityfacilitates migration towards an all-IP solution and permits a continueduse of CS network infrastructure such as MSC-S. In particular, theinterconnecting approach allows for a provision of CS services tonetwork component having a PS network access (e.g., via a WCDMA network,via a GPRS network or via WLAN). In this connection, the switchingcomponent (MSC-S) moves at least in part from the control layer to theapplication layer and becomes an application server, and the MSS-ASintermediates between the IMS control layer and the MSS applicationlayer. It should be noted here that the invention can not only bepracticed in layered networks of the MSS type, but also in conventionalnetworks. In such a case, the tasks in relation to CS services discussedabove may be provided by an appropriately configured MSC.

The solutions illustrated in the above embodiments offer a standard wayof providing CS telephony and other services to IMS clients. They alsopermit a smooth migration from CS to IMS and a reuse of installedequipment for operators.

While the current invention has been described in relation to itspreferred embodiments, it is to be understood that this disclosure isonly illustrative. Accordingly, it is intended that the invention belimited only by the scope of the claims appended hereto.

1. A method of controlling the provision of circuit-switched (CS)services to a first network component having a packet-switched (PS)network access, the method comprising: receiving PS control informationaccording to a PS control protocol from the first network component, thePS control information including CS control information according to aCS control protocol; extracting, in response to receipt of the PScontrol information. the CS control information from the PS controlinformation; and sending, according to the CS control protocol, theextracted CS control Information to a second network component locatedon an application layer for controlling, based on the determined CScontrol information, provision of CS services to the first networkcomponent.
 2. The method of claim 1, wherein the PS control informationincludes at least one of: one or more PS control messages and one ormore PS control parameters; and the CS control information includes atleast one of one or more CS control messages and one or more CS controlparameters.
 3. The method of claim 1, wherein the CS control informationis encapsulated in the PS control information, and wherein the step ofextracting the CS control information from the PS control InformationIncludes de-encapsulating the CS control information from the PS controlinformation.
 4. The method of claim 1, wherein the CS controlInformation is specified in the form of CS control parameters in the PScontrol information, and wherein the step of extracting the CS controlInformation from the PS control information includes extracting the CScontrol parameters from the PS control information and generating a CScontrol message including the extracted CS control parameters.
 5. Themethod of claim 1, wherein the CS control information includes one ormore of: information pertaining to a requested service type, informationrequired to establish CS services, information about how to execute CSservices, and information about the status or result of CS services. 6.The method of claim 1, wherein the step of determining the CS controlinformation is performed by services intermediating between a PS controllayer and a CS application layer.
 7. The method of claim 1, wherein thesecond network component is one of a MSC server (MSC-S) and a mobilesoftswitch (MSS).
 8. The method of claim 1, further comprising providingfirst services Interpreting the PS control information by default andsecond services capable of extracting the CS control information fromthe PS control information.
 9. The method of claim 8, further comprisingrouting the received PS control information to the first services, andre-routing the PS control information from the first services to thesecond services.
 10. The method of claim 9, further comprising the stepof deciding, by the first services, whether or not to re-route the PScontrol information.
 11. The method of claim 10, wherein the decision isbased on at least one of a service portfolio of the first services and arequest included in the received PS control Information.
 12. The methodof claim 8, further comprising selectively routing the PS controlinformation to either one of the first services and the second services.13. The method of claim 12, wherein the routing to either one of thefirst services and the second services is dependent upon one or more ofthe following criteria: the CS services requested, load-balancingconsiderations, capabilities of the first network component, triggerevents defined by a network operator, user requests, and user serviceprofiles.
 14. The method of claim 1, further comprising the steps ofreceiving CS control information; and determining, in response toreceipt of the CS control Information, PS control Information accordingto the PS control protocol.
 15. The method of claim 14, furthercomprising sending the determined PS control information to the firstnetwork component.
 16. The method of claim 1, further comprising thestep of registering the first network terminal having the PS networkaccess in a CS domain. 17.-18. (canceled)
 19. A device forinterconnecting packet-switched (PS) and circuit-switched (CS) domains.the device comprising: a control component for receiving PS controlinformation according to a PS control protocol from the first networkcomponent, the PS control information including CS control informationaccording to a CS control protocol; a protocol converter for extracting,in response to receipt of the PS control information, the CS controlinformation from the PS control information; and an interface forsending, according to the CS control protocol, the extracted CS controlinformation to a serving network component that is located on anapplication layer and provides the CS services based on the determinedCS control Information.
 20. The device of claim 19, wherein the protocolconverter includes program code for at least one of mapping the receivedPS control information to predefined CS control information; andde-encapsulating the CS control information from the PS controlinformation.
 21. The device of claim 19, wherein the generator isco-located with one of the control component, the serving networkcomponent and a service component that handles the PS controlinformation by default.